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(54) Tide: METHOD AND APPARATUS FOR DETERMINING COMMISSION 



(57) Abstract 

The invention provides for a 
method and apparatus for determin- 
ing the commission to be paid to a 
sales representative or sales teams. 
Based on a set of Allocation Rules 
(210) that specify the credit an indi- 
vidual is to receive from a Transac- 
tion (200), the Transactions are con- 
verted into several Allocations (202) 
for individual Sales Representatives 
or Sales Teams. One or more Quo- 
tas (212) specify a target of goal 
that must be reached to eam commis- 
sion for each Sales Team. A Quota 
State (206) indicates the current per- 
formance of a Sales Representative 
with respect to a particular Quota 
within a particular time frame. The 
Quotas are used to convert the Allo- 
cations/Transactions into Quota De- 
tails (204) that specify how to incre- 
ment or decrement the Quota State 
(206). A Promotion (216) specifies 
the reward or commission that is re- 
ceived upon attaining a desired level 
of performance. Once a Quota State 
reaches a level necessary to receive a 
commission or reward as set by a spe- 
cific Promotion, a Ledger Item (208) 
indicating the amount to be paid to 
particular Sales Team is created. 
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METHOD AND APPARATUS FOR DETERMINING COMMISSION 

BACKGROUND OF THE INVENTTONJ 
5 1. FIELD OF THE INVENTION 

This invention relates to the field of determining the sales 
commission provided to sales teams and representatives. 

10 Portions of the disclosure of this patent document contain material 

that is subject to copyright protection. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent document or the patent 
disclosure as it appears in the Patent and Trademark Office file or records, but 
otherwise reserves all copyright rights whatsoever. 

15 

2. BACKGROUND ART 

In modern business environments, it is commonplace to employ sales 
representatives to market the goods and services offered for sale. Sales 
20 representatives receive compensation based on a salary, the hours worked, 
and /or on the goods or services sold. When basing compensation on the 
goods or services sold, sales representatives receive a commission that can be 
based on profits, net sales, the number of products sold, or some other 
variable. 

25 

To provide sales representatives with an incentive to sell as much as 
possible or to sell more of a desired product or products at certain prices, sales 
organizations create incentive plans wherein Commissions (also referred to 
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as Promotions) are provided or offered to the sales representatives when 
specific sales goals or targets are attained during a defined time period. For 
example, a Promotion may consist of paying a bonus of $50 if a blue hammer 
is sold in the month of July or paying $1 for each of the first 1000 hammers 
sold and $2 for any additional hammer sold in the month of July. Some 
incentive plans provide for individual sales representatives to be 
apportioned credit towards a promotional level (such as a bronze, silver, or 
gold level) when a sale is made. 

In addition, an incentive plan may apportion credit (towards a 
Promotion) to everyone on a sales representative's sales team, to the 
representative's manager, or someone other than the sales representative 
himself. Providing credit to persons in a selling chain (i.e., an immediate 
supervisor, a manager, a senior manager, etc.) is referred to as an override or 
rolling up (a "roll-up") the selling chain. Figuring out who should be 
apportioned credit for a sale can be complex and difficult to administer. This 
is particularly true when a company has several different types of sales people 
from direct representatives, external agents, telemarketers, to distributors and 
resellers. The increasing use of sales teams, account territory, and product 
managers has further complicated the management of sales crediting. 

The management of a business can spend a great deal of time and 
money in developing incentive plans. In the prior art, the creation and 
distribution of incentive plans is a slow process that is prone to error. Large 
businesses merely print up or email a plan to retailers. The retailers add 
Promotions and targets to the plan and distribute the plan to the sales 
representatives. To calculate the payment or Promotion each sales 
representative will receive, the sales information is mailed back to the 
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businesses headquarters where the calculations and determinations are made. 
The Promotion or payment is then transmitted back to the retailer and 
distributed to the sales representative. Mistakes in the calculations can often 
be made at headquarters requiring a repetition of the entire process. Often the 
sales representatives do not receive a copy of the plan prior to making sales. 
Consequently, the sales representatives are unaware of the basis for their 
compensation or how an incentive plan works until after compensation is 
received (which can occur one or two payment periods after the sales have 
occurred and after the promotion's time period has expired). Such a delay 
defeats the underlying purpose of an incentive plan to promote the sale of 
particular products or services (i.e., the sales representative does not know 
what products or services the sales organization desires to promote). 

In today's competitive environment, companies thrive (and survive) 
on the basis of being able to quickly change and evolve. This is especially true 
in the sales and marketing area where rapid business changes are the norm. 
Competitive companies cannot afford being obligated to adhere to a static 
information infrastructure or a slow incentive plan process that cannot keep 
up with a rapidly changing business environment. 

In a traditional system solution, the particular business rules are 
broken down into their core components, which in turn are programmed 
using some computer language. The traditional system is adequate to 
represent a rigid and static business problem, like a general ledger or 
inventory system, for example. However, the traditional system is costly 
when trying to represent a quickly changing business environment like that 
of a sales organization, which role is to constantly change and to evolve to 
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align itself to changing customer needs, market changes, sales channels and 
internal business initiatives. 



Retailers are often not permitted to modify or create their own 
5 incentive plans for the sales representatives. An incentive plan can only be 

selected from a list of predefined plans created at a business headquarters. 

Further, sales representatives can often manipulate an incentive plan (by 

their actions) to obtain additional compensation unintended by management. 

In addition, the ability to view and organize information regarding sales 
10 transactions is unavailable or difficult in the prior art. Thus, retailers cannot 

easily observe statistics such as the products or services that are selling 

quickly, which sales teams or representatives are selling the most, the average 

cost a particular product is being sold for, etc. 

15 Thus, a system that quickly communicates an incentive plan to sales 

representatives, accurately and effectively calculates compensation to be paid 
to sales representatives, and allows flexibility to adjust an incentive plan as 
needed in a rapidly changing environment is desired. 
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SUMMARY OF THE INVENTTOM 

The invention provides for a method and apparatus for determining 
the commission to be paid to a sales representative or sales team. Whenever 
a sale occurs, a Transaction describing the sale is created and inputted into the 
Commission System of one embodiment of the invention. Based on a set of 
Allocation Rules that specify the credit an individual is to receive from a 
Transaction, the Transactions are converted into one or more Allocations for 
individual Sales Representatives or Sales Teams. 

One or more Quotas specify a target or goal that must be reached to 
earn commission for each Sales Team. A Quota State indicates the current 
performance of a Sales Representative with respect to a particular Quota 
within a particular time frame. The Quotas are used to convert the 
Allocations/Transactions into Quota Details that specify how to increment or 
decrement the Quota State. 

A Promotion specifies the reward or commission that is received upon 
attaining a desired level of performance. Once a Quota State reaches a level 
necessary to receive a Commission or reward as set by a specific Promotion, a 
ledger item indicating the amount to be paid to a particular Sales Team is 
created. 

A user interface may be used to create Allocation Rules, Quotas, and 
Promotions that are awarded for performance over a specified time period. 
In this manner, a business may set up incentive plans and determine 
commissions easily and accurately. 
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BRIEF DESCRIPTION OF TH E DRAWING 

Figure 1 is a block diagram of one embodiment of a computer system 
capable of providing a suitable execution environment for an embodiment of 
the invention. 

Figure 2 illustrates the flow of transactions and the components that 
provide the mechanisms that govern the flow in accordance with one 
embodiment of the invention. 

Figure 3 illustrates the properties of several objects in accordance with 
one embodiment of the invention. 

Figure 4 illustrates one or more allocation in accordance with one 
embodiment of the invention. 

Figure 5 is a screen print-out of a Rule Template Editor in accordance 
with one embodiment of the invention. 

Figure 6 demonstrates a method for calculating the current 
performance of a sales representative with respect to a quota in accordance 
with one embodiment of the invention. 

Figure 7 demonstrates a method for calculating the current 
performance of a sales representative with respect to a quota in accordance 
with one embodiment of the invention. 
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DETAILED DESCRIP TION OF THE INVENTION 

The invention is a method and apparatus for determining 
commission. In the following description, numerous specific details are set 
5 forth to provide a more thorough description of embodiments of the 
invention. It is apparent, however, to one skilled in the art, that the 
invention may be practiced without these specific details. In other instances, 
well known features have not been described in detail so as not to obscure the 
invention. 

10 

Embodiment of Computer Execution En vironment (Hardware! 

An embodiment of the invention can be implemented as computer 
software in the form of computer readable code executed on a general 

15 purpose computer such as computer 100 illustrated in Figure 1, or in the form 
of bytecode class files running on such a computer. A keyboard 110 and 
mouse 111 are coupled to a bi-directional system bus 118. The keyboard and 
mouse are for introducing user input to the computer system and 
communicating that user input to processor 113. Other suitable input devices 

20 may be used in addition to, or in place of, the mouse 111 and keyboard 110. 
I/O (input/output) unit 119 coupled to bi-directional system bus 118 
represents such I/O elements as a printer, A/V (audio/video) I/O, etc. 

Computer 100 includes a video memory 114, main memory 115 and 
25 mass storage 112, all coupled to bi-directional system bus 118 along with 
keyboard 110, mouse 111 and processor 113. The mass storage 112 may 
include both fixed and removable media, such as magnetic, optical or 
magnetic optical storage systems or any other available mass storage 
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technology. Bus 118 may contain, for example, thirty-two address lines for 
addressing video memory 114 or main memory 115. The system bus 118 also 
includes, for example, a 32-bit data bus for transferring data between and 
among the components, such as processor 113, main memory 115, video 
5 memory 114 and mass storage 112. Alternatively, multiplex data/address 
lines may be used instead of separate data and address lines. 

In one embodiment of the invention, the processor 113 is a 
microprocessor manufactured by Motorola, such as the 680X0 processor or a 

10 microprocessor manufactured by Intel, such as the 80X86, or Pentium 

processor. However, any other suitable microprocessor or microcomputer 
may be utilized. Main memory 115 is comprised of dynamic random access 
memory (DRAM). Video memory 114 is a dual-ported video random access 
memory. One port of the video memory 114 is coupled to video amplifier 

15 116. The video amplifier 116 is used to drive the cathode ray tube (CRT) 

raster monitor 117. Video amplifier 116 is well known in the art and may be 
implemented by any suitable apparatus. This circuitry converts pixel data 
stored in video memory 114 to a raster signal suitable for use by monitor 117. 
Monitor 117 is a type of monitor suitable for displaying graphic images. 

20 

Computer 100 may also include a communication interface 120 
coupled to bus 118. Communication interface 120 provides a two-way data 
communication coupling via a network link 121 to a local network 122. For 
example, if communication interface 120 is an integrated services digital 
25 network (ISDN) card or a modem, communication interface 120 provides a 
data communication connection to the corresponding type of telephone line, 
which comprises part of network link 121. If communication interface 120 is 
a local area network (LAN) card, communication interface 120 provides a data 
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communication connection via network link 121 to a compatible LAN. 
Wireless links are also possible. In any such implementation, 
communication interface 120 sends and receives electrical, electromagnetic or 
optical signals which carry digital data streams representing various types of 
information. 

Network link 121 typically provides data communication through one 
or more networks to other data devices. For example, network link 121 may 
provide a connection through local network 122 to local server computer 123 
or to data equipment operated by an Internet Service Provider (ISP) 124. ISP 
124 in turn provides data communication services through the world wide 
packet data communication network now commonly referred to as the 
"Internet" 125. Local network 122 and Internet 125 both use electrical, 
electromagnetic or optical signals which carry digital data streams. The 
signals through the various networks and the signals on network link 121 
and through communication interface 120, which carry the digital data to and 
from computer 100, are exemplary forms of carrier waves transporting the 
information. 

Computer 100 can send messages and receive data, including program 
code, through the network(s), network link 121, and communication 
interface 120. In the Internet example, remote server computer 126 might 
transmit a requested code for an application program through Internet 125, 
ISP 124, local network 122 and communication interface 120. In accord with 
the invention, one such application is that of determining the commission to 
be disbursed to a sales representative. 
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The received code may be executed by processor 113 as it is received, 
and /or stored in mass storage 112, or other non-volatile storage for later 
execution. In this manner, computer 100 may obtain application code in the 
form of a carrier wave. 

5 

Application code may be embodied in any form of computer program 
product. A computer program product comprises a medium configured to 
store or transport computer readable code, or in which computer readable 
code may be embedded. Some examples of computer program products are 
10 CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard 
drives, servers on a network, and carrier waves. 

The computer systems described above are for purposes of example 
only. An embodiment of the invention may be implemented in any type of 
15 computer system or programming or processing environment. 

Utilization pf Computer Software 

In one embodiment of the invention, computer software that utilizes 
20 multiple related functions and data structures is utilized. To encapsulate 

these related functions and data structures, one embodiment of the invention 
utilizes a standard object oriented programming (OOP) language approach. 
To provide an understanding of encapsulation of related data structures and 
methods, an overview of object-oriented programming is provided below. 

25 
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Object-Oriented Programming 

Object-oriented programming is a method of creating computer 
programs by combining certain fundamental building blocks, and creating 

5 relationships among and between the building blocks. The building blocks in 
object-oriented programming systems are called "objects." An object is a 
programming unit that groups together a data structure (one or more 
instance variables) and the operations (methods) that can use or affect that 
data. Thus, an object consists of data and one or more operations or 

10 procedures that can be performed on that data. The joining of data and 
operations into a unitary building block is called "encapsulation." 

An object can be instructed to perform one of its methods when it 
receives a "message." A message is a command or instruction sent to the 
15 object to execute a certain method. A message consists of a method selection 
(e.g., method name) and a plurality of arguments. A message tells the 
receiving object what operations to perform. 

One advantage of object-oriented programming is the way in which 
20 methods are invoked. When a message is sent to an object, it is not necessary 
for the message to instruct the object how to perform a certain method. It is 
only necessary to request that the object execute the method. This greatly 
simplifies program development. 

25 Object-oriented programming languages are predominantly based on a 

"class" scheme. The class-based object-oriented programming scheme is 
generally described in Lieberman, "Using Prototypical Objects to Implement 
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Shared Behavior in Object-Oriented Systems/' OOPSLA 86 Proceedings, 
September 1986, pp. 214-223. 

A class defines a type of object that typically includes both variables and 
5 methods for the class. An object class is used to create a particular instance of 
an object. An instance of an object class includes the variables and methods 
defined for the class. Multiple instances of the same class can be created from 
an object class. Each instance that is created from the object class is said to be 
of the same type or class. 

10 

To illustrate, an employee object class can include "name" and "salary" 
instance variables and a "set_salary" method. Instances of the employee 
object class can be created, or instantiated for each employee in an 
organization. Each object instance is said to be of type "employee." Each 

15 employee object instance includes "name" and "salary" instance variables 
and the "set_salary" method. The values associated with the "name" and 
"salary" variables in each employee object instance contain the name and 
salary of an employee in the organization. A message can be sent to an 
employee's employee object instance to invoke the "set_salary" method to 

20 modify the employee's salary (i.e., the value associated with the "salary" 
variable in the employee's employee object). 

A hierarchy of classes can be defined such that an object class definition 
has one or more subclasses. A subclass inherits its parent's (and 
25 grandparent's etc.) definition. Each subclass in the hierarchy may add to or 
modify the behavior specified by its parent class. Some object-oriented 
programming languages support multiple inheritance where a subclass may 
inherit a class definition from more than one parent class. Other 
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programming languages support only single inheritance, where a subclass is 
limited to inheriting the class definition of only one parent class. 

An object is a generic term that is used in the object-oriented 
5 programming environment to refer to a module that contains related code 
and variables. A software application can be written using an object-oriented 
programming language whereby the program's functionality is implemented 
using objects. The encapsulation provided by objects in an object-oriented 
programming environment may be extended to the notion of transactions, 
10 allocations, quotas, quota details, quota states, and promotions as discussed 
below. 

In one embodiment of the invention, a shell object mechansim is 
utilized to store and provide access to objects and data. Such a mechanism is 
15 discussed in detail in pending U.S. Patent Application Serial Number 

08/931,878 entitled "Method and Apparatus for Providing Peer Ownership of 
Shared Objects" which is hereby incorporated by reference. 

20 Embodiment of Object Model for Determining Commissions 

One embodiment of the invention provides the ability to determine 
Commissions and amounts payable to sales representatives (referred to as a 
"Commission System"). The Commission System provides an open, 
25 extensible object model that allows the business user to define any number of 
arbitrary properties (also referred to as hierarchies or object hierarchies) that 
model the structures associated with a business, such as a business 1 
customers, products, and sales teams (in addition to a default model that 
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specifies a set of hierarchies). These properties can then be used through a 
Commission calculation process to determine the payment for a sales 
representative. 

5 Hierarchies 

One model of the invention consists of a set of five (5) components or 
hierarchies: Sales Representative, Product, Customer, Quota, and Plan. 

10 Sales Representative 

The Sales Representative hierarchy represents the sales 
organization of a business and the person or entity that makes a sale. It can 
represent and may consist of individual sales representatives, or sales 
manager(s), a selling group/team, a retailer, or any number of arbitrary 

15 organizations. The Sales Representative hierarchy is used to represent the 
individual or group that makes a sale. "Sales Representative" is used 
interchangeably with "Sales Team" to represent an individual or group of 
persons throughout this document. Sales teams/groups are stored in a 
hierarchy tree, which is used to represent and manipulate different 

20 organization groups. A sales team can belong to one or several groups in the 
tree. 
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Product 

The Product hierarchy represents what is being sold. A Product 
can be a product idenfitication number, product group, or category, for 
example. Products are similarly stored in a hierarchy tree, which can be used 
5 to represent products lines, promotional groups, regionality (where a product 
is sold or built), categories, etc. 

Customer 

The Customer hierarchy represents the customer that a product 
10 is sold to. A Customer hierarchy can represent an individual customer or 
account. Similar to Sales Representatives and Products, Customers are stored 
in a hierarchy tree, which in turn can represent industries, territories, 
regions, type of sales, and other customer segments. 

15 Quota 

A Quota, also referred to as a Performance or Bucket, defines the 
sales performance to track and accumulate. Quotas can be defined to track 
any performance measure (units, sales volume, profit margin, etc.) over any 
time period (weekly, monthly, quarterly, yearly, etc.) across any number of 

20 sales teams (sales reps, sales teams, regions, etc.) Quotas are used to calculate 
bonuses and Commissions, sales tracking and other types of performance 
measures. 

Plans 

25 Plans define the reward for a certain performance and consists of 

a collection of Promotions (also referred to as a Bonus, Commission, or 
Compensation). Plans are the link between performance and earnings. 
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Promotions calculate an earnings payment based on a formula using one or 
several performance variables. 

In addition to the above default hierarchies, one embodiment of the 
invention permits the creation or specification of additional arbitrary 
hierarchies by a user. Additional hierarchies can represent actual groups or 
entities (such as employees) or non-existent groups that may be used to collect 
statistics. 

Processing Sales Transactions 

The hierarchies defined above maintain data and methods to enable 
the Commission System to efficiently and accurately process sales. Figure 2 
demonstrates the processing that occurs in one embodiment of the invention 
from the sale of a Product or service to payment of a Commission to a Sales 
Representative. The Commission Model 218 indicates the mechanism which 
governs how the processing occurs. When a sale is made, a sales transaction 
200 is input into the system. Through a set of rules 210, Sales Representatives 
are apportioned or allocated credit in the form of Allocations 202. Quotas 212 
and 214 process the Allocations 202 into Quota Details 204 that contain the 
change in the current status of the sales representative's progress towards a 
Promotion. The current status is also referred to as the Quota State or Quota 
State Performance 206. The amount a Sales Representative is to receive as a 
result of the sales transactions is determined by a calculation in a Promotion 
Object 216. Once determined, the amount is converted into a Ledger Item 208 
and distributed out to the Sales Representative. 
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To provide an understanding of how each object of the Model 218 
governs the commission process, each object and its affect on the transaction 
flow through the Commission System/engine will be discussed in detail 
below. 

5 

Transactions 

Transactions contain information regarding a sale and may be viewed 

10 as a line item in a sales order. Each transaction is independent from each 
other such that the order in which a transaction occurs or is entered into the 
system is not relevant. Referring to Figure 2, the input to the Commission 
system is a Model 218 and a set of Transactions 200. The Model 218 is static, 
and describes the Promotions, Products, and organizational hierarchy 

15 referenced by the incentive program. The Transactions 200 typically describe 
who sold what to whom and when. A Transaction may also answer the 
questions "why?", "how many?", and "for how much?". Transactions 200 
may be arbitrarily extended to contain any number of properties and these 
properties may later be referenced or used by other components and 

20 hierarchies of the system. Referring to Figure 3, a Transaction's properties 
may be basic types (e.g., types 308-312), sub-objects (e.g., sub-objects 302-306), or 
basic types of sub-objects (e.g., types 314-336). A default Transaction 200 may 
contain properties for a Sales Representative 302 (the Sales Representative 
who made the sale), a Product 304 (what was sold), a Customer 306 (who 

25 bought the product), the Date of the Sale 308, the Unit Price 310, and Quantity 
sold 312. 
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It is often the case, however, that the person who makes the sale is not 
the only person who gets credit for the sale. Often, a Sales Representative's 
Manager may get credit for some portion of the sale. Alternatively, the 
person in charge of the product that was sold should get credit for the sale. 
5 Additionally, a Transaction 200 may not indicate a Sales Representative; 
credit may need to be decided by some set of predefined rules. Further, one 
person may belong to several different groups at the same time (referred to as 
multiple inheritance). For example, one embodiment of the invention 
provides the ability for Jon Smith to be a member of Sales Team Blue, Sales 
10 Team Red, and Sales Manager over Lucy all at the same time. In this 

manner, Jon may receive credit through various sales that Jon himself did 
not initiate. Multiple inheritance may also be utilized to create virtual sales 
teams to maintain statistics and information. 

15 

Allocations 

The Commission System uses the term "Allocation" 202 to indicate 
credit allocated to a single individual or group on a single sale/Transaction. 

20 An allocation may be viewed as a Transaction that is tied to a Sales 

Representative at a certain weight. Referring to Figure 4, an Allocation 202 
may be an object that references the Transaction 200, a Sales Team or 
Representative 402 who will get credit for mat Transaction 200, and the 
percentage weight of credit 404 for the Transaction that the Sales 

25 Representative 402 receives. The total weight of all Allocations 202 for a 
single Transaction 200 does not need to total one (1) or 100%. In Figure 4, 
each allocation is represented by a row. For example, as demonstrated in 
Figure 4, transaction number one may result in sales team blue being 
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allocated 2% credit and John Smith, the sales representative, being allocated 
100% credit. Transaction number 2 may result in Mark Adams, the sales 
representative, being allocated 100% credit and Mark Adam's manager being 
allocated 3% credit. 

Allocation Rules 

The mechanism that decides how Allocations 202 are created from 
Transactions 200 is the set of "Allocation Rules" 210. To understand how 
Allocation Rules 210 are written, it is best to look at the kind of questions an 
Allocation Rule 210 will need to address. For a given Transaction 200, the 
following are examples of how Allocations 202 may need to be created. 
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Example I. 

1. If Sales Representative Joshua made the sale, give Joshua 100% credit 
for the sale. 

2. If sales manager Eileen or anyone working under her made the sale, 
give Eileen 20% credit for the sale. 

3. If the color of the Product sold is "Red', give 5% credit to 'The Red 
Team 1 . 

4. If the sale was made to any of the 'Large Customers', give John 10% 
credit. 

5. If the number of units sold is between 100 and 500, give 5% credit to 
Brennan. 



Each of the examples above represents a different type of Allocation. 
To understand the use of Allocation Rules to allocate credit, it is useful to 
examine the type of Allocation generically. Referring to the examples above, 

5 situation 1 is a Sales Team or Sales Representative type of Allocation wherein 
a Sales Representative, Josh, is allocated credit for a Transaction. Situation 2 
is a Roll-up type of Allocation wherein a Sales Manager, Eileen, is allocated 
credit for a Transaction made by another person. The Transaction is rolled- 
up the selling chain to the sales manager, Eileen. Situation 3 is a property of a 

10 product type of transaction wherein a property of a product, the color, is being 
utilized to allocate credit for the Transaction. Situation 4 is a property of a 
Customer type of transaction wherein a property of a customer, large 
customer, is utilized to allocate credit for the Transaction. Situation 5 is a 
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quantity in a range type of Allocation wherein a quantity range, the number 
of. units sold, is utilized to allocate credit for the Transaction. 

It is useful to have a language that has the ability to describe each of 
5 these conditions/situations, in any (boolean) combination. Rule Templates 
may provide this ability. In one embodiment, a Rule Template is the 
mechanism for describing how the user expects the rules to "look". The Rule 
Template is used both in generating Allocations 202, and in filtering or 
determining eligible Quotas (discussed below). 

10 

A Rule Template consists of a collection of Allocation Rules 210. Each 
Allocation Rule 210 is represented by a Name (or number) and a collection of 
Rule Attributes. Each Rule Attribute corresponds to a qualitative description 
of one of the examples above; the Rule Attribute contains a Transaction-based 
15 Property, an Operation, and an Alias. If all of the conditions in Example 1 

need to be handled at once, the following Rule Attributes would be present in 
the Rule Template (Table 1): 





Property ' ; 


Operajipn 


-Alias . f 




SalesTeam 




Sales Representative 


|1 


SalesTeam 




Sales Manager 




Product.Color 




Color 




Customer 




Customer 


5a 


Quantity 


> 


Quantity Min 




Quantity 


< 


Quantity Max 



Table 1 
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Referring to Figure 3 and Table 1, "Property" is a sub-property of the 
Transaction object 200 which will need to be referenced. This can be a "deep 
property", like "Product.Color" 324, that is a property of an object (e.g., 
Product 304) referenced from the Transaction 200. The "Operation" describes 
5 how to match the value, and the "Alias" is simply how the user interface will 
display this attribute. Figure 5 is a screen shot of the Rule Template Editor 
user interface that allows for the creation and modification of a Rule 
Template as provided by one embodiment of the invention. 

10 Referring to Table 1, row 1 represents a rule in which a sales 

representative is allocated credit for a sale. The user views the person 
allocated credit in the Sales Representative Property as a Sales Representative 
(the alias). Row 2 represents a rule in which the Sales Manager is allocated 
credit for a sale made by any of the Sales Representatives that she manages 

15 (i.e., the sales manager's children in the SalesTeam hierarchy). The Sales 
Manager's children's sales are rolled up to allocate credit to the Sales 
Manager. This representation is similar to the representation in Row 1 but 
for a different person being allocated credit. The user views the person 
allocated credit in the Sales Representative Property as the Sales Manager. 

20 Row 3 represents a rule in which the color of a product determines who is 
allocated credit. The user interface displays "Color" (the alias) that is 
represented by the Property Product.Color. Row 4 represents a type of 
customer that is allocated credit and the user views the term "Customer". 
Situation 5 of Example 1 is represented by two sets of Rule Attributes in Table 

25 1, rows 5a and 5b. Row 5a represents that the Quantity Property must be over 
a certain minimum for credit to be allocated. Row 5b represents that the 
Quantity must be less than a certain maximum for credit to be allocated. The 
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user interface displays the alias Quantity Min and Quantity Max in rows 5a 
and 5b respectively. 

Notice that a "value" is not part of a Rule Attribute; the quantitative 
5 "Joshua", 20%, 'Red', etc. is missing. These values are stored in the 

Allocation Rules themselves. The Rule Attributes describe how the Rules 
"look" (i.e., a generic representation of the rules), while the Rules themselves 
contain the actual conditions. Thus, the Rule Template provides a generic 
representation of the types of rules that may be utilized by the user. By 
10 storing Rule Attributes in a Rule Template in this manner, a user can later 
create rules for allocating credit with other values. For example, using the 
Rule Attributes in Table 1 above, a user can later create a rule that specifies 
any type of quantity range, product color, sales manager, sales representative, 
or type of customer. 

15 

Referring to Figure 2, a Commission Model 218 contains a collection of 
Rule Sets. In one embodiment a different rule set is stored for each Sales 
Team or Sales Representative. A Rule Set consists of a Rule Template (i.e., 
the generic set of type of rules available), a collection of Allocation Rules 210, 

20 and the "Recipient" - the Sales Team or Sales Representative that utilizes this 
particular rule set. An Allocation Rule is "fired" when every condition of the 
rule is met. Each Allocation Rule consists of the allocation weight to be 
credited for the resulting Allocation, a collection of values, and a collection of 
Rule Attributes. Each value corresponds to a Rule Attribute, and the rule 

25 will fire if all of the conditions in the Rule Attribute are met. Thus, an 
Allocation rule can be viewed as a set of pairs of Rule Attributes and 
corresponding Values. Referring to Figure 2, for every Allocation Rule 210 
that fires, one Allocation 202 is created. 
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The rules corresponding to Example I above are illustrated in Table 2 
below. Note that for figure simplicity the recipient (not shown) for all these 
rules is the same, since the rules are assumed to be utilized by the same Sales 
5 Team or Sales Representative. 





Saks Rep 


Sales : 


Color 

. . • ;. . 


Customer 
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t Quantity: 
Minimum 


Quantity 


Weight 
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Joshua 












1.00 






Eileen 










0.20 
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Red 








0.05 


4' 








Large 

Customers 






0.10 


fi 










100 


500 


0.05 



Table 2 



Each rule contains conditions that must be met. In rule 1 the value of 
10 the Sales Representative must be "Joshua". In Rule 2, the Sales Manager 
value must be equal to "Eileen". In Rule 3, the Color value must be "Red". 
In Rule 4, the Customer value must be "Large Customers". The fifth rule 
contains two conditions which must both be met, the Quantity Minimum 
value must be 100 and the Quantity Maximum Value must be 500. The 
15 allocation weight column illustrates that weight that will be allocated if each 
condition is met. 

To illustrate the above allocation rules, assume that Eileen is Joshua's 
Manager, and Joshua sells 400 Red Hammers to "The Large Tool Store". In 
20 this scenario, five different Allocations will be created: (1) an allocation to 
Joshua for 1.00; (2) an allocation to Eileen for 0.20; (3) an allocation to the Red 
Team for 0.05; (4) an allocation to John for 0.10; and (5) an allocation to 
Brennan for 0.05, with a total weight of 1.4 times the original Transaction. 
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Quota 

A Quota (also referred to as a Quota object) may be viewed as a target 
that each Sales Representative is trying to reach. It is the end goal or target 
that is set up in an incentive program that a Sales Representative must reach 
in order to earn the Commission. Since earning a Commission may be based 
on a specified time period, a Quota instance is created for each time period 
desired. Further, each Quota instance contains a collection of additional 
objects in the system that maintain the current state of performance for each 
individual Sales Representative (referred to as Quota State, discussed below). 
Each Quota contains four (4) distinct categories or properties that characterize 
the Quota's behavior: (1) a Temporal property; (2) a Performance Measure; (3) 
Eligibility Rules; and (4) Levels (also referred to as Quota Levels). In addition, 
a fifth property, Targeted, specifies whether targets are to be set on a SalesTam 
by SalesTeam basis (rather than using the same Quota for multiple 
SalesTeams). The Temporal property provides for a time period within 
which the Quota is measured. The Performance Measure provides the ability 
to quantify a transaction and determine how much a specific transaction is 
worth. The Eligibility Rules determine which Transactions the Quota is 
interested in to determine whether a commission should or should not be 
paid (i.e., the standards to reach the target). The Quota Level property 
provides the range(s) needed to reach or earn a commission. To better 
understand these properties and their relationships, each property is 
discussed in detail below. 
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Temporal Property 

A Quota is expected to accumulate statistics for some well- 
defined time period, and then restart at the beginning of the next period. For 
example, a monthly Quota would track performance for January, February, 
etc. At the beginning of each new month, performance would begin at zero. 
If a Transaction does not occur within the specified time period, then a 
particular Quota is not interested in that particular Transaction. 

There are four time-related properties: Start Date, Duration Unit, 
Duration Quantity, and Total Periods. The Start Date property contains the 
date the time period is to begin. The Duration Unit property specifies the type 
of time period being used (e.g., monthly, yearly, daily, etc.). The Duration 
Quantity property specifies how many times the Duration Unit property 
repeats for one Quota (e.g., if Units=Months and Quantity=2, the Quota 
period last for two months). The Total Periods property specifies how many 
Quota periods the calculations will be accumulated for. 

For illustrative purposes, compare a Quota which begins on 1/1/98 
with Quantity = 2, Units = "Months", and Periods = 6; with a Quota beginning 
on 1/1/98 with Quantity = 1, Units = "years", and Periods = 1. Both Quotas 
become inactive on 1/1/99, but the first Quota will have six bi-monthly 
"buckets" (and will repeat and collect statistics six (6) times), while the latter 
will have one large bucket for the entire year. 

In another embodiment of the invention, the Temporal properties 
include a start date and end date. Further, multiple instances of the same 
Quota object may be created and instantiated with different or overlapping 
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starting and ending dates. In this manner, time periods can accumulate for a 
single Quota to earn a single Commission. For example, if the target is to sell 
1000 hammers in January and 1000 hammers in February, if Jon sells 0 
hammers in January and 1200 hammers in February, it may appear that Jon is 
5 entitled to earn a Commission based on the February performance. However, 
by maintaining multiple instances, the system can determine that to "catch 
up" Jon must earn 2000 hammers by the end of February to earn any 
Commission. Further, in such an embodiment, the time periods can overlap. 
For example one time period may run from January 1 to February 1, while 
10 another time period for the same Quota can nm from January 15 to February 
15. Allowing overlapping time periods permits the user to accumulate 
statistics in various manners or use an increase in sales over multiple 
specified time periods to determine whether a Commission is due. 

15 When the temporal properties are applied to specific Allocations or 

Transactions, a boolean result is returned. If the Transaction occurred within 
the specified time period, True or 1 is returned, and if the Transaction 
occurred outside of the specified time period, False or 0 is returned. 

20 

Eligibility Rules 

If there is no way to describe which Transactions a Quota is 
interested in, only a single Quota is needed, to count all Transactions sold. 
25 Eligibility Rules determine the Transactions that a Quota is interested in or 
that a Quota will use in its determination of a whether a Sales Representative 
has attained the desired target. In this respect, Eligibility Rules may be viewed 
as a filter of Transactions. For example, Quota A may only be interested in 
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how many red trucks were sold or how the top salespersons are performing. 
Any transaction that does not include information regarding red trucks or top 
salespersons, respectively, would not be utilized by Quota A in determining 
the Commission. Thus, although Eligibility Rules may appear similar to 
5 Allocation Rules, Allocation Rules create Allocations (a non-boolean result) 
that determine which Sales Representative will earn credit for a particular 
Transaction. Eligibility Rules determine which Transaction is eligible for a 
Quota to use in calculating a Commission (a boolean result of true if the 
Transaction is eligible and false if the Transaction is not). 

10 

The Eligibility Rules are established and set up in the same manner as 
Allocation Rules with Rule Attribute- Value pairs and do not have specific 
targets associated with the rule. However, dissimilar to Allocation Rules, 
Eligibility Rules do not have a Sales Representative and Weight associated 

15 with the result. Eligibility Rules contain a set of conditions. An Eligibility 
Rule will "fire" or return a true result if any condition specified is met ("OR" 
logic is utilized). For example, assume an Eligibility Rule contains the 
following conditions: (1) Transactions containing "red sedans"; (2) 
Transactions with quantites greater than 2000; and (3) Transactions with blue 

20 trucks. If either condition (1), condition (2), or condition (3) is met, the rule 
will "fire" and return a true result. 

Performance Measure 

25 Once the Commission Engine knows which Transactions apply 

to a Quota, the Transaction must be quatified. The Performance Measure is a 
way to quantify a transaction. The Performance Measure consists of a Name 
of a property (in the Transaction object) and a mathematical formula using 
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the Transaction properties which, when evaluated, tell the Quota how much 
that Transaction was worth. It provides the ability to quantify and assign a 
number to a Transaction which may be subsequently used for calculations. 



5 Example 2 illustrates some sample Performance Measures: 





Name jForrtisila | 


H!!§ ; -- 


Units 


Quantity 


2 


Revenue 


Quantity * Unit Price 


mm. . 


Profit 


Quantity » (Unit Price - Product.MfgCost) 



Example 2 



Referring to Example 2, Performance Measure 1 is titled Units and is 
10 equal to the Quantity property in a Transaction. Performance Measure 2 is 
titled Revenue and is based on the Quantity in the Transaction and the Unit 
Price for each item in the Transaction. Performance Measure 3 is titled Profit 
and is based on the Quantity in the Transaction times the profit for a quantity 
of one (e.g., the price of one unit (Unit Price) - the manufacturing cost of a 
15 product (Product.MfgCost)). Performance Measure 3, Profit, illustrates how to 
use a property of the Product sold. Such a use is possible as long as "Product" 
is an object property on Transaction, and the sub-object has a "MfgCost" 
(manufacturing cost) property. Similarly, Transaction must have top-level 
Quantity and UnitPrice properties. Nested properties of arbitrary depth are 
20 supported, as long as the resulting property is of the correct type (e.g., a 
number). 

Consider a Transaction in which 1000 hammers were sold for $2.50 
each. Some Quotas may be interested in the fact that 1000 hammers were sold 
25 (total quantity), while others may be interested in the fact that the Transaction 
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generated $2,500 in revenue. Various Performance Measures provide the 
ability to quantify the Transaction in the desired method. Example 2 above 
demonstrates three sample Performance Measures. 

r 

Quota Levels 

The Quota Levels property consists of a collection of Levels. A 
Level is an abstraction that specifies a range or goal that the Sales 
Representative must attain in order to earn a specific Commission. Each 
Level contains a Name, a Start, and an End. Table 3 illustrates a collection of 
three Levels: 









m 




II Bronze 


0 


3,000 




Silver 


3,000 


4,000 




1 Gold 


4,000 


Infinity 



Table 3 



In one embodiment, Quota Levels must be non-overlapping and have 
non-negative lower bounds (Starts). Table 3 illustrates that to attain the 
Bronze Level, the Sales Representative must attain between 0 and 3,000. To 
attain the Silver Level, the Sales Representative must attain between 3,000 
and 4,000. To attain the Gold Level the Sales Representative must attain 4,000 
or more. Table 3 illustrates a targeted Quota or a Quota that is targeted for a 
particular SalesTeam or Sales Representative. 

The bounds only make sense in the context of the Performance 
Measure; if the measure is Units, a Sales Representative must sell 3000 units 
to reach "Silver" level, while if it is Profit, he must sell 3000 dollars. It is 
often the case that the user will want both large and small Sales Teams to 
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belong to the same Quota. But it hardly seems fair that the smaller team 
must perform as well as the larger team to achieve their goals. For this 
reason, it is possible to set targets independently for each participant in a 
Quota. A Quota's participant set is defined as the union of the participants of 
5 all the Promotions that reference that Quota (Promotions are discussed 

below). Each QuotaLevel in a "targeted" Quota is relative to the target; that is, 
the upper and lower bounds will be fractions around 1.0. If a Sale Team's 
target is 4000, Table 3 corresponds exactly with Table 4. 
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1.00 
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Gold 


1.00 


Infinity 



Table 4 



In Table 4, each bound in the Level is divided by the total target 
amount of 4,000. Thus, the End bound for the Bronze Level and Start bound 
for the Silver Level is equal to 3,000/4,000 or 0.75. Similarly, the End bound 
15 for the Silver Level and Start Bound for the Gold Level is equal to 4,000/4,000 
or 1.0. In this manner, the fractions may be applied to particular Sales Teams 
with differing goals (e.g., a goal of 4000, 1000, or 20000) merely by multiplying 
each bounds fraction times the target. Table 4 is a non-targeted Quota that is 
not dependent on a particular SalesTeam but applies to any SalesTeam. 

20 

Quota State 



25 



In one embodiment of the invention , each instance of the Quota 
objects discussed above are utilized as a container for a set of Quota States, 
one for each participant (or Sales Representative). The Quota State also 
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contains the current up-to-the-minute performance information for each 
Sales Representative. A Quota State may contain the following properties: (1) 
Sales Representative; (2) Performance (the current performance of the Sales 
Representative); and (3) Target (what the Sales Representative needs to 
achieve). 

The Performance property of a Quota State maintains the current 
status and performance of a particular Sales Representative with respect to a 
particular Quota. Thus, the Performance property is dynamic and changes as 
the various Transactions flow through the system. 

The Target Property of a Quota State provides the total end target for 
that particular Sales Representative. As discussed above the Target property 
can be multiplied against every fraction specified in the bounds of a Quota 
Level to determine the number necessary for a particular Sales 
Representative to attain a level. To determine the current Level of a Sales 
Representative, the performance of a Sales Representative stored in the 
Performance property (which has not been broken down into fractions) is 
divided by the Target property. The result produces a fraction that can be 
compared to the Quota Level properties to determine the Sales 
Representative's status. For example, if the Target is 10000, and the current 
Performance is 2500, the current status of the Sales Representative is 
Performance divided by Target or 2500/10000 = 0.25. 0.25 is then compared to 
the Quota Level property to determine which Level the Sales Representative 
has attained. 

In one embodiment of the invention, the Target property can consist of 
a rule instead of a constant number, to impose higher level logic for target 
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calculation. For example, a target may specify a rule requiring a 3% increase 
over the prior year's performance. 

Evaluating the interrelationships of the Transactions, Quota object and 
Quota State to determine the Performance of a Sales Representative may be 
done several ways. 

One method for calculating the current Performance of a Sales 
Representative towards a specific Quota is illustrated in Figure 6. At step 600, 
all of the Transactions that have taken place are examined. At step 602, all of 
the Allocations for each Transaction are examined. At step 604, each 
Allocation for a particular Sales Representative is identified. At step 606 it is 
determined if each Transaction represented by the Allocation is within the 
specified time period in the Quota object. At step 608, it is determined if each 
Transaction represented by the Allocation is eligible under the Quota 
Eligibility Rules. If the Allocation is eligible and in the appropriate time 
period, the Performance Measure for that Transaction is multiplied by the 
weight according to the Allocation at step 610 and added to a running total of 
the Sales Representative's performance at step 612. 

The following calculation represents the current state of an individual 
Sales Representative with respect to a Quota in accordance with the above 
method: 
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f(Q,P,S) = X 'ZU'KA.SalesTean = S) * Q.Eligiblel(T )Q.Measure(T ) * A. Weight 

T«Tra«j(Q.P) AtT.AIloa 

where: 

Trans(Q, P) = {T\ T. TransDate > I. StartDate and T. TransDate < I. EndDate and / = Q. Ins tan c 
T. Allocs = {Allocations associated with T} 
T = T with T.SalesTeam = S 
= true 



fl x = 

' = {o „. 



U?(x) , 



[0 otherwise 



Another way to view the process of determining the current 
Performance of an individual Sales Representative is illustrated in Figure 7. 
At step 700, all of the Transactions (or a set of Transactions) are entered into 
the system. At step 702, the Allocations for the Transactions are created. At 
step 704, the method iterates over each Allocation and locates the instance of 
the relevant eligible Quota for the desired time period. At step 706, a Quota 
Detail is created. A Quota Detail contains the change that will result in the 
current Performance state. Thus, a Quota Detail is the mechanism to track 
the changes in a Quota State. At step 708, the corresponding Quota State for 
the Sales Representative desired is located and the Quota Detail is added to 
the Quota State at step 710. 



Promotions 

Once the performance statistics have been accumulated in the Quota 
State, there needs to be a way to specify how to pay Sales Representatives 
based on their Performance. A Promotion (also referred to as a Bonus of 
Commission) provides that mechanism. A Promotion consists of a reference 
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to a single primary Quota, a collection of Sales Representative participants, 
and a collection of Promotion Rules. Each Promotion Rule, when fired, 
generates a Ledger Item indicating a payment to a Sales Representative. 

Promotion Rules 

A Promotion Rule has two components: (1) a Quota Level 
predicate; and (2) a Reward Formula. When a participant's Performance 
reaches a rule's predicted level, the rule fires, and the Sales Representative 
receives credit equal to the value specified by the reward formula. The 
reward formula is a mathematical formula with variables supplied by the 
appropriate Quota State. Table 5 demonstrates some sample Promotion 
Rules. 
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Quota Level 
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1 SI 
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100 
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Silver 


Performance * 10 


3 




Performance / Target * 9000 






Ratio * Reward 


5 




Ratio & SalesTeam.Salary * 0.05 


•6;? 1 




Rank < 5 ? (5 - Rank) * 100 : 0 



Table 5 



The first rule imparts a $100 reward on a participant that reaches the 
'Bronze' Quota Level; that is, when a participant Sales Representative 
achieves the Bronze level, a Ledgerltem is created with Credit equal to 100. If 
the Performance Measure of the Promotion's Quota is "Units", then the 
second rule pays $10 for each item sold if the participant reaches the 'Silver' 
level. (If the Performance Measure is "Revenue", however, the second rule 
doesn't make much sense, in that the recipient would receive ten times as 
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much revenue as he brought in.) Any property in the Quota State may be 
used in the Reward Formula. 

A rule need not have a Quota level predicate (e.g., rules 3-6); if no 

5 predicate exists, the rule always fires. Also more than one rule in a 

Promotion can fire, either due to the lack of a predicate, or overlapping Quota 
Levels. The third rule references both the Sale Team's performance and his 
target and creates a ratio that is multiplied times a reward amount. Rule 3 
pays on a sliding scale, in which the participant receives exactly $9,000 when 

10 the target is met, $4500 at 50% of the target, etc. In one embodiment, the 

Performance/Target ratio may be replaced with a variable "Ratio" that can be 
used in its place. For the same reason that a user may desire to set targets 
individually for each Sales Representative, it is advantageous to set the 
reward value ($9000 here) on a participant by participant basis as well (e.g., pay 

15 a larger amount to a large sales team). For that reason, the Quota State object 
has a "Reward" property in addition to Performance and Target. Therefore, if 
every Sales Representative's Reward value was equal to 9000, rule 3 and rule 
4 above are identical. In truth, any number of additional properties can be 
added to the Quota State object, and thereafter the properties can be used in 

20 Promotional Rules. 

The participant corresponding to a Quota State is available through the 
Quota State's "Sales Representative" property. Thus, all of the participant's 
properties are also available in the reward formula. Rule 5 demonstrates this; 
25 it rewards a Sales Representative that achieves its target with 5% of the 
Representative's base salary. 
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In addition to the Quota State variables, four (4) types of additional 
"Rank" related variables are available for use in a Reward Formula that allow 
rules based on where a Sales Representative ranks relative to other 
participants in the Promotion or Quota: (1) Rank: the rank of a Sales 
5 Representative in a group (e.g., the most sales or the top four sellers); (2) 
Quota Rank: the rank among Quotas; (3) Ratio Rank: the rank based on 
percentage sales and not raw sales; and (4) Quota Ratio Rank. 

The "Rank" variable corresponds to the cardinality of the Sale Team's 
10 raw performance compared with all the other participants of this Promotion. 
Quota Rank is the same rank taken from the participants of the Quota, which 
is a superset of the Promotion's participants. Ratio Rank (also referred to as 
Percent Rank) and Quota Ratio Rank (also referred to as Quota Percentage 
Rank) are similar rank variables that are based on performance as a 
15 percentage of target, rather than raw performance. Rule 6, which uses the 
branching operator (?:) pays $400 to the highest ranking Sales Representative, 
$300 to the second, $200 to the third, $100 to the fourth, and nothing to the 
rest. 

20 The Ratio and Rank variables do not reside on the Quota State object, 

but are supplied specifically for the Promotion Rules by the Commission 
System /Engine. 

25 Multi-QuotaLevel Predicates 



Incentive plans may have rules that are based on the successful 
attainment of multiple goals. For example, a user may not want to give a 
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reward to a Sales Representative unless the representative sells 10,000 
hammers and 10,000 saws. The Quotas for 10,000 hammers and 10,000 saws 
may be stored in separate Quotas if these amounts are being utilized to attain 
another Promotion, for example. For this reason, a Promotion may have 
zero or more secondary Quotas, and Promotion Rules with multiple 
corresponding Quota Level Predicates. 
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Silver 


Satisfactory 


0.07 * Performance 




Gold 


Satisfactory 


0.10 * Performance 



Table 6 



Table 6 demonstrates some examples of multi-quota level promotion 
rules. A Sales Representative must achieve Silver level in the primary 
Quota, and he must be Satisfactory in the secondary Quota in order to receive 
a bonus of 7% of his sales. Note that if a Sales Representative has not 
achieved Bronze or Satisfactory levels, he will not receive any credit (no rule 
will fire). 

One embodiment of the invention provides that the variables in the 
reward formulae are all based on Quota States from the primary Quota and 
the formula may not use performance statistics from the secondary Quotas. 
Another embodiment of the invention provides full Multi-Quota support in 
which a reward formula would be able to use the Performance, Target, and 
Reward variables from any dependent Quota. Another embodiment of the 
invention provides the ability to set a Promotion based on the ratio of specific 
products to total products (referred to as Penetration). For example, if the 
manufacturer does not want the Sales Representative to sell too many red 
hammers, a ratio of 1:4 may be utilized. 
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Retroactive versus Point-Forward 

One embodiment of the invention provides for an additional 
property of a Promotion that affects the output of the Commission Engine 
(i.e., the amount paid to a Sales Representative). This property is a string or 
flag that indicates whether calculations are to be performed retroactively or 
point forward (also called incrementally). The effect of this property is best 
illustrated through example. Consider a simple non-targeted monthly Quota 
beginning on 1/1/97, which tracks sales of hammers. This Quota has "Units" 
as the Performance Measure, and two Quota Levels: 











Bronze j 0 


1000 




Silver \ 1000 


Infinity 



Consider also a Promotion referencing this Quota; with two rules: 









Bronze 1 Performance 




Silver | Performance * 2 



Finally, imagine that there are two eligible Allocations: 





TransDaie 


mSKSSKSM 


Product ISalesTeam 




T 


1/05/97 


! 500 


Hammer 


1 Joshua 


100% 


2 1 


1/20/97 


1 1000 


Hammer 


1 Joshua 


100% 



A Ledgerltem represents that amount paid to a Sales Representative 
and is discussed in detail below. An analysis of the Ledger Items generated 
demonstrates varying results dependent on the timing of the Engine 
execution. For example, assume that the Engine is run once, on February 
first. The natural assumption would be to look at the total performance, 1500, 
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decide that Joshua has achieved the Silver level, and should therefore receive 
a payment of $3,000. This type of analysis corresponds to a "Retroactive" 
Promotion, in which the final level achieved applies retroactively to the 
beginning of the period. If the same example is utilized but the Engine run 
5 twice, on 1/15/97, and again on 1/31/97, a different result is likely. When the 
Engine is first run, the total performance is 500, so a Ledgerltem with a credit 
of $500 is generated (the Bronze level rule fires). At the end of January, the 
total performance is 1500, so a Ledgerltem is generated for $2,500, which is the 
total $3,000 deserved minus the $500 already paid out. 

10 

Point-Forward promotions specify that when a Sales Representative 
reaches a new Quota Level, Promotion Rules for that level only apply for 
subsequent Transactions. In other words, the Sales Representative only 
achieves a reward for that portion of items sold in a specific level. Consider 

15 the example above for a Point-Forward promotion with two Engine 
executions. The first payment would still be $500, as Joshua is 
unambiguously within the Bronze level on 1/15/97. However, the second 
payment is difficult to determine. The case could be made for three different 
amounts: $1,000 (1000 hammers sold keeping Joshua in the Bronze level), 

20 $1,500 (500 hammers sold to complete the first 1000 in the bronze level for 
$500 and 2*500 for the next 500 hammers sold in the Silver level), or $2,000 
(1000*2 for 1000 hammers sold in the silver level). 

The second transaction places Joshua into the Silver level. If this 
25 transaction qualifies for the Silver level rule, it would generate a $2,000 
Ledger Item. If this transaction does not qualify (because it "began" in the 
Bronze level), it would generate a $1,000 Ledger Item. In both of these cases, 
the transaction order becomes very important. For example, if a third 
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transaction arrives dated 1/10/97 (out of order), it would be necessary to 
process not just the new transaction, but also to reprocess the transaction 
from 1/15/97. It seems counter-intuitive that two unrelated transactions 
have such an effect on one another. 

5 

In one embodiment, the Engine defaults to Point Forward analysis and 
generates the final possible answer discussed above: $1,500. This quantity can 
be determined by examining the Promotion Rules and the total Performance 
(1500 units). Of the total Performance of 1500, 1000 are in the Bronze level 
10 ($1,000), and 500 are in the Silver level ($1,000). Since the system has already 
paid out $500 from the first transaction, it creates a new Ledger Item for 
$1,500. 



15 Ledger Items 

A Ledger Item indicates the amount paid to a Sales Representative. 
Whenever a Quota Detail is created (indicating a change in Quota State 
performance), the Quota State, Quota Instance, and Quota's time stamp is 

20 updated with the current time. When the Commission System/Engine is 
asked to pay a Promotion, it finds all Quota States that have been changed 
since the Promotion was last paid. For each of those Quota States, the Engine 
calculates the total amount of credit that should be paid to the Sales 
Representative, based on the Quota State and the Promotion Rules. It is 

25 possible to determine the amount to be paid directly from the Quota State; 
there is no need to examine the Transactions or Allocations which 
contributed to that Quota State (this ability is discussed below). 
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Once the total amount of money to be paid is known, the Engine finds 
the amount of money which has already been paid (by querying for all Ledger 
Items associated with this Promotion, Sales Representative, and Period), and 
generates a new Ledger Item for the difference (if non-zero). The output of 
5 the Commission is not dependent on the frequency that the engine is run. 
For example, the output will be the same if the engine is run every night or 
once a month. By maintaining multiple Ledger Items, flexibility is allowed 
over time. For example, a user who wants to write a check number on 
Ledgerltems when they are sent to payroll can do so. 

10 

Another feature of creating Ledger Items is the ability to implement 
Draws. A Draw is when a Sales Representative is paid ahead of time for 
expected sales. By creating a Ledgerltem representing each of these payments, 
it is possible to use a reconciliation function to repay the draw. Since the 

15 Engine always subtracts the total amount paid from the total amount which 
should have been paid, the next time the Engine is run, it will credit a 
Ledgerltem debiting the amount of the Draw. To delay the reconciliation, the 
"ignore" property on each Draw Ledgerltem may be set to True. (Transactions 
have a similar Ignore property, indicating that the Engine should not process 

20 them). 



Effectivity Dating 

One embodiment of the invention provides for effectivity 
dating. Effectivity Dating provides the ability to specify when specific Quotas 
and Promotions apply to specific individuals. Such an ability is useful when 
a Sales Representative or Manager moves from one location to another. 
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Effectivity Dating ensures that the Representative's prior sales are taken into 
account at the new location in determining Promotions that the 
Representative may receive. 

Optimization to Performanrp 

When discussing Engine performance, it is important to realize that 
the design of the commission model greatly influences the time it takes to 
process Transactions. Typically, performance is measured in number of 
Transactions processed per hour, as the computation time will scale linearly 
in that parameter. In one embodiment a write transaction to a database 
occurs at the rate of 50-100 rows/second. When thousands or millions of 
rows are written to a database, the data write can take a considerable amount 
of time. 

Referring to Figure 2, various model characteristics affect processing 
time including the Allocation 202 to Transaction 200 ratio (that is, the average 
number of people who are allocated credit for a single sale), the Quota Detail 
204 to Allocation 202 ratio (that is, the average number of "Quotas", or 
performance metrics, to which each Allocation applies), and the total number 
of Quotas 212 in a model. Commonly, the Allocation Ratio (A:T) is in the 3-8 
range, the Quota Detail Ration (D:A) is in the 1-6 range, and the number of 
Quotas range anywhere from 20-200. 

In one embodiment three tables are utilized to store all Transactions: 
(1) a table for the base of all objects; (2) a table for the base of commission 
objects; and (3) a table for the object itself. Whenever an Allocation or Quota 
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Detail is created, a row is added to all three tables. In one embodiment the 
commission object table is eliminated. By eliminating the use of one table, 
the number of transactions stored on the databases are reduced by 1/3. In 
another embodiment, all three tables are combined into one table reducing 
5 the number of transactions on a database by 2/3. 

In one embodiment of the invention, the least important transactions 
are delayed until a time when a computer processor is available for a large 
period of time (e.g., delayed until the weekend). The aspects of the invention 

10 that are used most frequently and must be current are the Quota State and 
Ledger items (i.e., the Sales Representative needs to have the ability to check 
the current performance level and total sales and the system needs to know 
how much to pay a Sales Representative). To accomplish this delay without 
forfeiting the integrity of the data, three tasks are performed: (1) 

15 Accumulation; (2) Unpacking; and (3) Compensation. 



WO 99/60486 



45 



PCT/US99/07118 



Accu m illation 

Accumulation is also referred to as the mainline of one 
embodiment of the invention. The Accumulation stage examines a set of 

5 Transactions, changes/updates the Quota States and produces a set of 
packages. A package is a binary string consisting of a compressed group of 
Allocations and Quota Details. One mechanism of a database that may be 
utilized is the ability to save a Binary Large Object (BLOB) more rapidly than 
the group of objects corresponding to the single BLOB. Thus, a package may 

10 be rapidly stored in a database using the BLOB functionality. However, 
saving a BLOB has one disadvantage of disabling the standard querying 
mechanisms of a database for those saved objects. 

Unpacking 

15 

The Unpacking task loads all of the packages, creates the 
relevant objects (e.g., the Allocations and Quota Details) and saves the objects 
to the database in the standard fashion. By delaying the creation of the Quota 
Detail Objects and Allocations until a later date, the largest processing portion 
20 of the invention is delayed while the Quota States are still current. 

Compensating 

25 The Compensating task examines the Quota States and creates 

ledger items (using the Promotion object). The Compensating task may be 
performed prior to the Unpacking task. 



WO 99/60486 



46 



PCT/US99/07118 



By using the three tasks above, Sales Representatives may examine 
their current Quota States and receive timely and current payment (through 
the ledger items) while delaying the largest processing portion (i.e., the Quota 
Details and Allocations) until a large portion of processing time is available 
5 (e.g., at night or on the weekend). 



Parallelization 

10 In one embodiment of the invention, the operations may be divided 

between several computers. For example, the Quota Details creation and 
write transactions may be divided amongst several computers each creating a 
separate but linear table. Subsequently, the tables may be concatenated 
together to create a single table for standard use. 

15 

In addition, the mainline computation can also be parallelized. If 
parallel processing (parallelization) is utilized for this^urpose, a fourth task 
of Aggregation is added to the three tasks discussed above. The Aggregation 
task aggregates all of the accumulated results on each individual machine 
20 into one table in the database. In such an embodiment, the ledger items are 
not activated for payment until the aggregation task has completed. 



25 



Thus, a method and apparatus for determining a commission is 
described in conjunction with one or more specific embodiments. The 
invention is defined by the claims and their full scope of equivalents. 
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CLAIMS 

1. A method for determining commission using a computer 
system comprising: 

obtaining one or more transactions; 

obtaining one or more quotas that specify one or more levels; 

obtaining one or more promotions that specify a reward for one or 
more of said levels; 

calculating a performance of a recipient based on said transactions; 

determining if said recipient's performance qualifies for said 
promotion; and 

determining compensation for said recipient using said promotion if 
said recipient's performance qualifies. 

2. The method of claim 1 wherein said obtaining one or more 
transactions step comprises inputting one or more transactions into said 
computer system. 

3. The method of claim 1 wherein one of said quotas further 
specifies: 

a time period; 

a set of one or more eligibility rules; and 
a performance measure. 

4. The method of claim 3 wherein said performance measure 
provides the ability to quantify said transaction. 
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5. The method of claim 3 wherein one or more of said eligibility 
rules determines whether one of said transactions applies to said quota. 

6. The method of claim 3 wherein said time period determines 
whether one of said transactions applies to said quota. 

7. The method of claim 1 wherein said reward comprises a 
mathematical formula. 

8. The method of claim 1 wherein said step of calculating a 
performance comprises: 

obtaining one or more allocations for said transactions; and 
adding an eligible allocation to a performance total. 

9. The method of claim 8 wherein said adding an eligible 
allocation step comprises: 

obtaining a change in performance based on said allocation; and 
adding said change in performance to a performance total. 

10. The method of claim 1 implemented in an object oriented 
environment. 

11. The method of claim 1 further comprising defining a property 
that may be used in said calculating step or determining steps. 

12. The method of claim 1 wherein said calculating performance 
step is executed using parallel processing on one or more of said computer 
systems. 
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13. The method of claim 12 wherein said parallel processing 
comprises: 

accumulating one or more packages containing details regarding said 
5 recipient's performance using multiple processors; 

unpacking said packages into objects containing said details; 
saving said objects containing details; and 
aggregating said saved objects into one or more tables. 



10 



14. The method of claim 8 wherein said obtaining an allocation step 
comprises processing an allocation rule that is based on one or more 
properties of a business. 
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15. The method of claim 1 further comprising displaying a report of 
said recipient's performance. 

16. A system comprising 
a processor; 

a memory coupled to said processor; 

object code executed by said processor for providing at least one 
method for determining a commission; 
said object code comprising: 

a method obtaining one or more transactions; 

a method obtaining one or more quotas that specify one or more 

levels; 

a method obtaining one or more promotions that specify a 
reward for one or more of said levels; 

a method calculating a performance of a recipient based on said 
transactions; 

a method determining if said recipient's performance qualifies 
for said promotion; and 

a method determining compensation for said recipient using 
said promotion if said recipient's performance qualifies. 



17. The system of claim 16 wherein said method obtaining one or 
more transactions comprises object code comprising a method for inputting 
one or more transactions into said system. 
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18. The system of claim 16 wherein one of said quotas further 
specifies: 

a time period; 

a set of one or more eligibility rules; and 
5 a performance measure. 

19. The system of claim 18 wherein said performance measure 
provides the ability to quantify said transaction. 

10 20. The system of claim 18 wherein one or more of said eligibility 

rules determines whether one of said transactions applies to said quota. 

21. The system of claim 18 wherein said time period determines 
whether one of said transactions applies to said quota. 

15 

22. The system of claim 16 wherein said reward comprises a 
mathematical formula. 

23. The system of claim 16 wherein said method calculating a 
20 performance comprises object code comprising: 

a method obtaining one or more allocations for said transactions; and 
a method adding an eligible allocation to a performance total. 

24. The system of claim 23 wherein said object code for adding an 
25 eligible allocation comprises: 

a method obtaining a change in performance based on said allocation; 

and 

a method adding said change in performance to a performance total. 
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25. The system of claim 16 further comprising object code for 
defining a property that may be used in said calculating method or 
determining method. 

26. The system of claim 16 wherein said method calculating 
performance is executed using parallel processing on one or more of said 
systems. 

27. The system of claim 26 wherein said parallel processing 
comprises object code comprising: 

a method accumulating one or more packages containing details 
regarding said recipient's performance using multiple processors; 

a method unpacking said packages into objects containing said details; 
a method saving said objects containing details; and 
a method aggregating said saved objects into one or more tables. 

28. The system of claim 23 wherein said method obtaining an 
allocation comprises object code processing an allocation rule that is based on 

20 one or more properties of a business. 

29. The system of claim 16 further comprising object code displaying 
a report of said recipient's performance. 



10 



15 
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30. A computer program product comprising: 

a computer usable medium having computer readable code embodied 
therein for determining a commission, said computer program product 
comprising: 

5 computer readable code configured to cause a computer to obtain one 

or more transactions; 

computer readable code configured to cause a computer to obtain one 
or more quotas that specify one or more levels; 

computer readable code configured to cause a computer to obtain one 
10 or more promotions that specify a reward for one or more of said levels; 

computer readable code configured to cause a computer to calculate a 
performance of a recipient based on said transactions; 

computer readable code configured to cause a computer to determine if 
said recipient's performance qualifies for said promotion; and 
15 computer readable code configured to cause a computer to determine 

compensation for said recipient using said promotion if said recipient's 
performance qualifies. 

31. The computer program product of claim 30 wherein said 
20 computer code configured to cause a computer to obtain one or more 

transactions comprises computer readable code configured to cause a 
computer to input one or more transactions into said system. 

32. The computer program product of claim 30 wherein one of said 
25 quotas further specifies: 

a time period; 

a set of one or more eligibility rules; and 
a performance measure. 
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33. The computer program product of claim 32 wherein said 
performance measure provides the ability to quantify said transaction. 

34. The computer program product of claim 32 wherein one or 
more of said eligibility rules determines whether one of said transactions 
applies to said quota. 

35. The computer program product of claim 32 wherein said time 
period determines whether one of said transactions applies to said quota. 

36. The computer program product of claim 30 wherein said reward 
comprises a mathematical formula. 

37. The computer program product of claim 30 wherein said 
computer code configured to cause a computer to calculate a performance 
comprises: 

computer readable code configured to cause a computer to obtain one 
or more allocations for said transactions; and 

computer readable code configured to cause a computer to add an 
eligible allocation to a performance total. 
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38. The computer program product of claim 37 wherein said 
computer code configured to cause a computer to add an eligible allocation 
comprises: 

computer readable code configured to cause a computer to obtain a 
change in performance based on said allocation; and 

computer readable code configured to cause a computer to add said 
change in performance to a performance total. 



39. The computer program product of claim 30 implemented in an 
object oriented environment. 

40. The computer program product of claim 30 further comprising 
computer readable code configured to cause a computer to define a property 
that may be referenced by said computer readable code configured to cause a 
computer to calculate or computer readable code configured to cause a 
computer to determine. 

41. The computer program product of claim 30 wherein said 
computer readable code configured to cause a computer to calculate 
performance is executed using parallel processing on one or more of said 
computer program products. 
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42. The computer program product of claim 41 wherein said parallel 
processing comprises: 

computer readable code configured to cause a computer to accumulate 
one or more packages containing details regarding said recipient's 
performance using multiple processors; 

computer readable code configured to cause a computer to unpack said 
packages into objects containing said details; 

computer readable code configured to cause a computer to save said 
objects containing details; and 

computer readable code configured to cause a computer to aggregate 
said saved objects into one or more tables. 

43. The computer program product of claim 37 wherein said 
computer readable code configured to cause a computer to obtain an 
allocation comprises computer readable code configured to cause a computer 
to process an allocation rule that is based on one or more properties of a 
business. 

44. The computer program product of claim 30 further comprising 
computer readable code configured to cause a computer to display a report of 
said recipient's performance. 
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